# AI 动态工作流详解

> 搞懂动态工作流的运作原理、技术架构，以及它在 AI 应用开发中的定位



大家好，我是程序员鱼皮。

Anthropic 在 5 月底发布 Claude Opus 4.8 的时候，同步推出了 Claude Code 的 **动态工作流** 功能。

有人用它 11 天完成了 75 万行代码的语言迁移，有人拿它做全代码库的安全审计。还有人说这玩意儿一跑起来，烧掉的 Token 比自己一个月用的还多……

最近有小伙伴面试的时候，就被问到「动态工作流」相关的问题了，但和很多同学一样，对这玩意的理解是模糊的。

它到底是模型自己学会的能力，还是工具层面搭出来的？跟之前的多 Agent 编排有什么区别？

如果面试官问你「动态工作流的本质是什么」，你能答清楚吗？

本文我就来把动态工作流讲清楚，带你搞明白动态工作流的运作原理、技术架构，以及它在 AI 应用开发中的定位。



## 动态工作流是什么？

动态工作流是让 AI 自己编写编排脚本，把一个大任务拆成若干子任务，分发给数十到数百个并行子 Agent 执行，最后汇总验证结果的能力。

![](https://pic.yupi.icu/1/01_%E5%8A%A8%E6%80%81%E5%B7%A5%E4%BD%9C%E6%B5%81%E6%A6%82%E5%BF%B5%E5%9B%BE-AI%E8%87%AA%E5%B7%B1%E7%BC%96%E6%8E%92%E5%AD%90Agent_compressed_v3.png)

注意，这里的关键词是 **让 AI 自己编写**。

以往我们做多 Agent 协作，不管是用 LangGraph 这种框架、还是自己写编排代码，任务怎么拆分、子 Agent 之间怎么协调、结果怎么合并，这些逻辑都是开发者手动定义的。你得提前想好有几个 Agent、每个 Agent 负责什么、上下游怎么串联。

而动态工作流不一样。你只需要告诉 AI 自己想做什么，比如「帮我把这个项目从 Python 2 迁移到 Python 3」，它会自己分析代码库的结构，决定需要几个子 Agent、每个子 Agent 负责迁移哪些文件、怎么并行执行、怎么验证迁移后的代码是否正确。

整个编排方案是 AI 根据你的具体任务实时生成的，不是预定义好的模板。

打个比方，传统的多 Agent 编排就像你当项目经理，需要自己画甘特图、分配任务、开站会跟进度。

动态工作流更像是你把需求丢给一个靠谱的技术总监，他自己去摇人、分活、盯进度、验收，最后给你交付结果。

![](https://pic.yupi.icu/1/02_%E4%BC%A0%E7%BB%9F%E7%BC%96%E6%8E%92vs%E5%8A%A8%E6%80%81%E5%B7%A5%E4%BD%9C%E6%B5%81%E5%AF%B9%E6%AF%94-%E9%A1%B9%E7%9B%AE%E7%BB%8F%E7%90%86vs%E6%8A%80%E6%9C%AF%E6%80%BB%E7%9B%91_compressed_v1.png)



## Agent 系统的分类

要理解动态工作流的技术定位，得先看看 Anthropic 官方是怎么给 Agent 系统分类的。

早在 2024 年 12 月，Anthropic 就发布了一篇非常经典的工程博客，叫 Building Effective Agents。

![](https://pic.yupi.icu/1/image-20260706185611910.png)

这篇文章把所有的 Agentic 系统分成了两大类。

第一类是 Workflow 工作流，特点是 LLM 和工具的协作路径是通过预定义的代码来编排的。你写好了流程，AI 按照流程走。

第二类是 Agent 智能体，特点是 LLM 自己动态决定接下来干什么、用什么工具、怎么推进任务。控制权在模型手里。

在 Workflow 这个大类下面，Anthropic 又细分了 5 种具体的模式。

1、Prompt Chaining 提示链

任务被拆成一连串固定步骤，前一步的输出是后一步的输入。比如先生成文案、再翻译成英文，两步是固定顺序。

2、Routing 路由

根据输入的类型把请求分发到不同的处理流程。比如客服系统里，退款问题走退款流程，技术问题走技术支持流程。

3、Parallelization 并行化

同一个任务拆成多个独立子任务并行执行，最后把结果汇总。比如让多个 Agent 分别从不同角度审查一段代码。

4、Orchestrator-Workers 编排者-工人

一个中心 LLM 作为编排者，动态地把任务分解，分配给多个工人 LLM 执行，然后综合它们的结果。这里的重点是「动态」，编排者不是按预定义的规则分配任务，而是根据具体输入来判断需要几个工人、每个工人干什么。

5、Evaluator-Optimizer 评估者-优化器

一个 LLM 生成结果，另一个 LLM 负责评估和提供反馈，循环迭代直到质量达标。

![](https://pic.yupi.icu/1/03_Anthropic%E4%BA%94%E7%A7%8DAgent%E7%B3%BB%E7%BB%9F%E6%A8%A1%E5%BC%8F%E6%A6%82%E8%A7%88-%E5%90%AB%E4%B8%AD%E6%96%87%E5%90%8D_compressed_v3.png)

你发现了吗？动态工作流本质上就是第 4 种模式 Orchestrator-Workers 的产品化实现。

注意，这不是一种新模式，而是同一个模式的不同实现方式。区别在于 **谁来搭建这个编排系统**。

传统做法是你自己用代码实现 Orchestrator-Workers。比如你要做一次全代码库的安全审计，你得用 LangGraph 或者自己写 Python 来搭这套编排逻辑：

```python
# 这是开发者自己写的编排器
files = scan_all_files(project_path)
risk_groups = classify_by_risk(files)
agents = []
for group in risk_groups.high:
    agents.append(Agent(task="deep_audit", targets=group))
for group in risk_groups.low:
    agents.append(Agent(task="quick_scan", targets=group))
results = run_parallel(agents)
report = merge_results(results)
```

这段代码运行起来确实是「动态」的，能根据实际文件情况做分配。但问题是，这个编排器本身是你写的。怎么扫描文件、怎么分级风险、起几个 Agent、每个 Agent 用什么策略，所有这些决策规则都得你自己设计。

而 Dynamic Workflows 的特点是 Claude Code 把这件事全包了。你只需要说一句「帮我审计这个项目的安全漏洞」，Claude 自己就会生成类似上面那段编排逻辑并执行。扫描文件、评估风险、分配任务、汇总结果，全部由模型在运行时自主完成。

一句话总结，**传统方式你是 Orchestrator-Workers 模式的开发者，Dynamic Workflows 里你是这个模式的使用者。**



## 动态工作流的运作机制

动态工作流的执行过程大致分为几个阶段。

1）首先是接收任务、制定计划。

Claude 会分析你的输入，理解任务的规模和复杂度，然后动态生成一份编排方案，决定需要启动多少个子 Agent、每个子 Agent 的职责是什么。这一步就像接到一个大项目后，技术负责人先评估工作量，再写一份招人计划和分工表。

2）计划确定后就进入分发执行阶段。

子 Agent 并行启动，各自处理分配到的子任务。目前系统最多支持同时运行 16 个并发子 Agent，总计上限 1000 个！

3）然后是交叉验证，这是动态工作流的一个亮点。

它不只是把子任务的结果简单拼起来，还会安排独立的验证 Agent 去检查其他 Agent 的输出。对于高风险任务，甚至会启动「对抗性 Agent」，专门尝试找茬、攻破前面 Agent 产出的结果。

如果验证不通过，相关的子 Agent 会被要求修正。**这个循环会持续进行，直到所有结果达到一致性标准。**

是不是很眼熟？

没错，又是 Loop Engineering 的思想。关于 Claude Code 官方的循环工程设计理念，可以阅读本教程经验技巧板块中的《Loop Engineering 保姆级教程》了解更多。核心就是让 AI 反复跑、反复改、直到完成目标为止。动态工作流把这个思路用到了极致，不仅仅是让一个 Agent 自己循环，而是一群 Agent 互相验证、互相纠错地循环。

4）最终把验证通过的结果汇总成一份完整的交付物，返回给用户。

整个过程中的进度是持续保存的，如果任务中途被打断，恢复后可以从断点继续，不需要从头开始。

![](https://pic.yupi.icu/1/04_%E5%8A%A8%E6%80%81%E5%B7%A5%E4%BD%9C%E6%B5%81%E8%BF%90%E4%BD%9C%E6%9C%BA%E5%88%B6%E5%9B%9B%E9%98%B6%E6%AE%B5%E6%B5%81%E7%A8%8B_compressed_v3.png)

此外还有一个关键设计，这个 **编排的执行发生在对话上下文之外**。

你可以这么理解，主对话窗口是你和技术总监沟通的会议室，而那些子 Agent 各自在独立的工位上干活。不管外面有多少人在并行工作，都不会挤占你会议室的空间。所以不管任务多大、涉及多少个子 Agent，都不会撑爆 Claude 的上下文窗口。这是它能处理跨越数百个文件的大规模任务的关键。

![](https://pic.yupi.icu/1/05_%E4%B8%8A%E4%B8%8B%E6%96%87%E9%9A%94%E7%A6%BB-%E4%BC%9A%E8%AE%AE%E5%AE%A4vs%E7%8B%AC%E7%AB%8B%E5%B7%A5%E4%BD%8D%E6%AF%94%E5%96%BB_compressed_v1.png)



## 动态工作流实战案例

动态工作流最震撼的案例来自 JavaScript 运行时 Bun 的开发者 Jarred Sumner。

他用动态工作流把 Bun 从 Zig 语言移植到了 Rust，整个过程 11 天完成，产出了大约 75 万行 Rust 代码，原有测试套件的通过率达到 99.8%。

这个迁移是怎么用动态工作流完成的呢？

Anthropic 官方博客透露了大致的过程。

首先，一个工作流负责遍历整个 Zig 代码库，为每一个结构体的每个字段映射出对应的 Rust 生命周期标注。这一步需要分析大量的类型关系和所有权语义。

然后，另一个工作流把数百个 .zig 文件分配给并行的 Agent，每个 Agent 把分配到的 .zig 文件翻译成行为等价的 .rs 文件。而且每个文件会安排两个审查 Agent 来检查翻译结果。

接下来是修复循环。一个工作流反复运行构建和测试，把编译错误和测试失败分发给对应的 Agent 去修复，直到整个项目能够正常编译并通过测试套件。

最后，一个通宵运行的工作流负责消除不必要的数据拷贝，并为每处优化单独创建一个 Pull Request 供人工审查。

整个过程中，人类开发者做的事情就是定义目标、确认方案、最后审查 PR。中间的具体实施全部由动态工作流自主完成。

![](https://pic.yupi.icu/1/07_Bun%E8%AF%AD%E8%A8%80%E8%BF%81%E7%A7%BB%E5%AE%9E%E6%88%98%E6%A1%88%E4%BE%8B%E6%B5%81%E7%A8%8B_compressed_v3.png)



## 动态工作流是模型能力还是工具能力？

这是一道很尖锐的面试题：动态工作流是模型自身具备的能力，还是平台工具提供的？

答案是 **两者缺一不可，但职责不同**。

**模型层面提供的是「智能」。**

比如：

- 任务规划能力，能把一个模糊的大目标拆解成具体的、可执行的子任务
- 上下文理解能力，能分析代码库结构、理解各文件之间的依赖关系
- 工具调用能力，能正确生成和执行编排脚本
- 还有自我纠错能力，能判断子任务的输出是否正确，以及如何修复

这就是为什么动态工作流是跟 Opus 4.8 一起发布的。Opus 4.8 在任务规划和判断力上有明显提升，它对自己代码中的缺陷的检出率是前代模型的 4 倍。这种自我检验的能力是动态工作流能做到「交叉验证」和「对抗性检查」的基础。

**平台层面提供的是「基础设施」。**

比如：

- 子 Agent 的生命周期管理，负责创建、调度、销毁
- 并发控制，限制最多 16 个同时运行
- 进度持久化，中断后可以恢复
- 上下文隔离，让编排逻辑不占用主对话的上下文窗口
- 以及最终的结果聚合和交付

用一个类比来理解，模型能力就像一个优秀的技术总监的大脑，他知道怎么拆任务、怎么分配人、怎么验收。

平台能力就像公司的项目管理系统和基础设施，提供了会议室、协作工具、版本控制、持续集成等等。

光有聪明的大脑但没有执行体系不行，光有系统但没人会规划也不行。

所以如果面试官问你这个问题，最准确的回答是，动态工作流是一种 **建立在强模型能力基础上的平台产品特性**。模型提供规划和决策的智能，平台提供并行执行和生命周期管理的基础设施，两者结合才构成完整的动态工作流。

![](https://pic.yupi.icu/1/06_%25E6%25A8%25A1%25E5%259E%258B%25E8%2583%25BD%25E5%258A%259Bvs%25E5%25B9%25B3%25E5%258F%25B0%25E8%2583%25BD%25E5%258A%259B-%25E5%25A4%25A7%25E8%2584%2591+%25E5%259F%25BA%25E7%25A1%2580%25E8%25AE%25BE%25E6%2596%25BD_compressed_v1.png)



## 和多 Agent 框架的区别

理解了上面的架构分层之后，再来看看动态工作流跟 LangGraph、CrewAI 这些多 Agent 框架的区别就很清晰了。

传统多 Agent 框架的思路是，开发者自己定义 Agent 的角色和能力，自己编写编排逻辑决定谁先执行、谁后执行、结果怎么传递，异常情况也要自己处理。框架给你提供了一堆现成的模块和连接方式，但具体怎么组装是你的事。

动态工作流的思路完全相反，开发者只需要描述最终目标，模型自动完成角色定义、任务拆解、编排逻辑生成、异常处理和结果验证。你连编排代码都不用写，因为 Claude 自己会写。

**这两种方式没有绝对的好坏之分，适用场景不同。**

如果你的任务是高度标准化的、流程固定的，比如每天定时跑一轮数据分析报告，用传统框架把流程写死会更稳定、更可控、成本更低。

如果你的任务是一次性的、规模大的、子任务不可预测的，比如代码库迁移、安全审计、大规模重构，动态工作流的优势就很明显了，因为你根本没法提前定义好所有的子任务和执行路径。



## 怎么用起来？

动态工作流目前在 Claude Code 的 CLI、桌面端和 VS Code 扩展中都可以使用，也可以通过 API 调用。

其他 AI 编程工具也在探索类似的多 Agent 并行模式，比如 Cursor 推出了 Cloud Agents 和后台 Agent 并行能力。不过目前「由模型自己编写编排脚本」这种玩法，Claude Code 的动态工作流是做得最完整、产品化程度最高的。

启动动态工作流的方法非常简单，有 2 种方法。

第一种是直接告诉 Claude 创建一个工作流，比如：

```markdown
创建一个工作流，帮我审计整个代码库的安全漏洞
```

第二种是在 Claude Code 的 effort 菜单里开启 `ultracode` 设置。这个设置会把推理力度调到最高，同时让 Claude 自动判断当前任务是否适合用工作流来处理。如果适合，它会自动切换到工作流模式。

第一次触发工作流时，Claude Code 会显示即将执行的计划并要求你确认，不会直接就跑起来。

有一点需要注意，动态工作流的 Token 消耗量远超普通的 Claude Code 会话。道理很简单，你同时雇了几十上百号人帮你干活，工资当然比只请一个人贵得多。

所以建议按需使用，先从一个小范围的任务开始试，感受一下消耗量级，再逐步扩大规模，别上来就对着整个代码库一把梭。



## 写在最后

看完这篇文章，你会发现 AI 应用开发正在从「开发者编排 Agent」向「Agent 编排 Agent」演进。开发者的角色在往上移，从写编排代码的执行者，变成定义目标和审查结果的管理者。

这个趋势意味着，以后做 AI 应用开发，光会用框架写 Agent 可能不够了，还需要对整个 Agent 架构体系有深入的理解。Anthropic 那篇 Building Effective Agents 提出的 5 种模式，基本就是这个领域的必备知识点，建议反复读。

希望这篇文章能帮你真正搞懂动态工作流，不管是面试还是实际使用，都能心里有底。AI 编程的世界变化很快，保持学习，你一定能跟上节奏！